-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[AWS] Use namespace for GetListMetrics when exists #41022
Conversation
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
|
Pinging @elastic/obs-ds-hosted-services (Team:obs-ds-hosted-services) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have this remark [1] otherwise, looks okay
[1] - https://github.com/elastic/beats/pull/41022/files#r1784739873
if len(namespaceDetailTotal) == 0 { | ||
listMetricsOutput, err = aws.GetListMetricsOutput("*", regionName, m.Period, m.IncludeLinkedAccounts, m.OwningAccount, m.MonitoringAccountID, svcCloudwatch) | ||
if err != nil { | ||
m.Logger().Errorf("Error while retrieving the list of metrics for region %s and namespace %s: %w", regionName, "*", err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to include the namespace in this error message?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I think that this is can be a good integration test to include it. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The error message here shows namespace is *
because in this if statement we are calling ListMetrics
with *
all namespaces. The else statement part is the one with a specific namespace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gizas, most integration tests start the metricset/input and check that they produce a non-zero number of events.
What kind of check do you have in mind?
What do you think about creating a dedicated issue to enhance the integration tests for the cloudwatch metricset?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kaiyan-sheng, this change may increase the number of API calls because we're making one API call for each namespace in the config.
However, it shouldn't make a difference since I don't expect configurations to have more than 1-3 namespaces, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zmoog Yeah that's the original thought when we decide to use "*" instead of individual namespace in this API call. But I think at this point, the benefit of using specific namespaces with a higher number of API calls wins.
I will update the document here: https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-module-aws.html#aws-api-requests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We actually already have tests around this but since we are mocking the ListMetrics API and what's returning from the API, the test is no use for distinguish namespaces. As we discussed earlier, I will merge this PR to get the fix in but look into the test later. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zmoog I tested the pr again with the config below to double check how many times this ListMetrics API will be called. Turned out we are calling it once because namespaces are the same in both parts under metrics:
- module: aws
period: 60s
metricsets:
- cloudwatch
data_granularity: 60s
include_linked_accounts: true
regions:
- ap-southeast-1
metrics:
- dimensions:
- name: CanaryName
value: canary1
namespace: CloudWatchSynthetics
- dimensions:
- name: CanaryName
value: canary2
namespace: CloudWatchSynthetics
This pull request is now in conflicts. Could you fix it? 🙏
|
/test |
I added the |
Please keep in mind that:
See this old PR for reference https://github.com/elastic/beats/pull/34055/files |
This pull request is now in conflicts. Could you fix it? 🙏
|
* Use namespace for GetListMetrics when exists (cherry picked from commit 36327a4)
* Use namespace for GetListMetrics when exists (cherry picked from commit 36327a4)
* Use namespace for GetListMetrics when exists (cherry picked from commit 36327a4) Co-authored-by: kaiyan-sheng <[email protected]>
…xists (#41175) * [AWS] Use namespace for GetListMetrics when exists (#41022) * Use namespace for GetListMetrics when exists (cherry picked from commit 36327a4) --------- Co-authored-by: kaiyan-sheng <[email protected]>
Proposed commit message
This PR is to change GetListMetricsOutput function (which calls the ListMetrics API) to use namespaces when namespaces are given in AWS CloudWatch configuration in Metricbeat.
Instead of returning all possible metrics from CloudWatch from ALL namespaces and filter later, we only need to query the ListMetrics API to get the metrics under the namespaces that we care about.
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.